1. The Field of the Invention
The present invention relates to computer network security, and more specifically, to mechanisms for uniformly representing and transferring security assertion and security response information.
2. Background and Relevant Art
Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, and database management) that prior to the advent of the computer system were performed manually. More recently, computer systems have been coupled to one another to form computer networks over which the computer systems can communicate electronically to share data. As a result, many of the tasks performed at a computer system (e.g., accessing electronic mail and web browsing) include electronic communication with one or more other computer systems via a computer network (e.g., the Internet).
Often, electronic communication on a computer network includes a client computer system (hereinafter referred to as a “client”) requesting access to a network service (e.g., electronic mail or a web page) at a server computer system (hereinafter referred to as a “server”). Frequently, network services are protected by security mechanisms such that only trusted clients are allowed to access the network services. Thus, when requesting access to a network service, a client may submit security input that includes or represents security assertions (e.g., a user-id, a password, a digital signature, etc.). The server can process the submitted security input and output a security response. When the client's security input is appropriate (e.g., when the client is authenticated and authorized), the server may output a security response that indicates access to the network service has been granted. On the other hand, when the client's security input is not appropriate, the server may output a security response that indicates access to the network service has been denied.
Security input can be submitted in any of a number of different data formats. Likewise, security responses can be output in any of a number of different data formats. In some environments, a client may request issuance of a service access token from a token issuance service. In these environments, a client submits security input in the form of a request that includes security assertions. If the security assertions included in the request are appropriate, the token issuance service can respond with security output in the form of a service access token. The client can then use the issued service access token as proof of trust to a server.
In other environments, a client may request exchange of a first service access token (that may represent one or more security assertions) from a token exchange service. In these other environments, a client submits security input in the form of the first service access token. If the first service access token is appropriate, the token exchange service can respond with security output in the form of a second service access token. The client can then use the second service access token (potentially along with one or more other tokens) as proof of trust to a server.
In yet other environments, a client may request validation of particular security assertions from a validation service. In these yet other environments, a client submits security input in the form of one or more security assertions. If the one or more security assertions are valid, the validation service can respond with security output in the form of an answer indicating that the one or more security assertions are valid (e.g., by signing the security assertions). The client can then use the answer as proof of trust to a server.
Unfortunately, a client and a server may not support the same formats for security input and/or for security output. This can lead to incompatibilities that prevent even a trusted client from being able to provide proof of trust to a server. For example, a client that only supports token issuance (and is thus configured to submit security input in the form of a request including security assertions) may have limited, if any, mechanisms for submitting security input to a token exchange service that only supports token exchange (and is thus configured to receive security input in the form of a service access token). Compatible communication may be even more difficult on networks (e.g., the Internet) where a client and a service are managed by different entities. For example, a user of the client may have limited, if any, ability to configure the service to receive security input in the form of a request that includes security assertions. Similarly, an administrator of the service may have limited, if any, ability to configure the client to submit security input in the form of a service access token.
In some network environments, a client and server (as well as any token issuance services, token exchange services, and validation services) may each use different specialized protocols to transfer security input and security output. For example, a client may be configured to send service access tokens using a Security Assertion Markup Language (“SAML”) protocol. However, a token exchange service may be configured to receive service access tokens using an XML Key Management Specification (“XKMS”) protocol. Thus, even through both the client and the token exchange service support service access tokens, the client may be prevented from submitting a service access token for exchange.
To potentially alleviate incompatibilities resulting from the use of different specialized protocols, computer systems on a network may maintain a protocol stack for each different type of specialized protocol. For example, a server may maintain both a SAML protocol stack for communicating with a client and an XKMS protocol stack for communicating with a validation service. However, maintenance of multiple protocol stacks consumes system resources (e.g., system memory) that would otherwise be available for use by other processes. Further, these specialized protocols typically differ from more generalized protocols used to transfer application data. However, for compatibility reasons, a computer system may be constrained to using a specialized protocol to transfer security input and security output.
In some environments, a server receives security input via a first protocol stack and then transfers the security input via a second different protocol stack to a validation service (or a token exchange service or issuance service). For example, a server that receives security input via a SAML protocol stack may transfer the security input via a XKMS protocol stack to a validation service. While waiting for security output via XKMS from the validation service, the server may be required to maintain state information (thereby consuming additional system resources) for the SAML protocol stack. Failure to maintain the SAML state information can result in the server being unable to appropriately send security output back to the client.
Therefore systems, methods, computer program products, and data structures for uniformly representing and transferring security assertion and security response information would be advantageous.